I'll test it tonight. But the problem I see now is, you always catch the exception with continue. That means the exception might always get ignored.

Will this be better?

        for i in range(3):
            try:
                s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
                s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
                s.settimeout(self.connection_timeout)
                s.connect((self.address, self.port))
                s.send(payload)
                data = s.recv(1024)
                s.close()
                return data
            except socket.error:
                if i >= 3:
                # raise some exception
                else:
                  continue

Good point, nice catch! I'll make that suggested edit now.

@left4taco Updated to handle like so

except socket.error as e:
    if i == 2:
        raise ConnectionError(e)
    else:
        continue

The problem I found with this modification is, getting status too frequently will toggle the switch randomly. This is also mentioned in some ticket but I cannot find it.

Hmm, that's peculiar behavior. I would think with the retry logic it should only fetch upon errors.

Any suggestions? I mainly need this retry logic for actually setting the status since it sometimes fails with the current setup.

@BillSobel retry logic moved to set_status function (since that's where it sometimes fails for me).
@left4taco mind testing the new edit?

No problem. Will test when I get home.

The changes look good to me.

Any word on this? Curious if @BillSobel has had a chance to test this and if he noticed any negative side-effects or if it did in fact improve successful state-change rate.

Ahh, my mistake, sorry! In that case, guess I'm looking for @clach04's input then.

Sorry for delay in responding.

Code looks good BUT for re-try logic I'd like to see it parameterized rather than hard coded (in this instance to 3).

Related bug where status calls causes state toggle is upstream issue is #84 (local issue #29) - I've yet to see this but I totally believe this is happening with some devices.

@clach04 No worries, I understand life gets busy. I agree that parameterizing the retry logic would be cleaner. How would you propose I do so though? Do you want me to implement an additional (optional) parameter to the def set_status(self, on, switch=1): function? Something along the lines of

def set_status(self, on, switch=1, retries=3):
        """
        Set status of the device to 'on' or 'off'.
        
        Args:
            on(bool):  True for 'on', False for 'off'.
            switch(int): The switch to set
            retries(int): Number of attempts to retry setting status in cause of failure.
        """
        # open device, send request, then close connection
        if isinstance(switch, int):
            switch = str(switch)  # index and payload is a string
        payload = self.generate_payload(SET, {switch:on})
        #print('payload %r' % payload)
        for i in range(retries):
            try:
                data = self._send_receive(payload)
                log.debug('set_status received data=%r', data)
            except Exception:
                if i == retries - 1:
                    raise Exception('set_status failed after exhausting defined consecutive attempts')
                else:
                    continue

        return data

Also, I see that you mention there is an upstream issue related to this. Does that mean we shouldn't be implementing this fix here or is that still ok?

I recently found it quite unstable. So I have to move the retry logic into _send_receive and retry for 10 times with a 100ms sleep between each retry.